Currently, installation of a loosely-defined (i.e., modifiable by either the administrative users of the service or required by an update to the service) set of platform-specific content in connection with a service that runs on a specified set of platforms can be performed in a variety of ways. For example, a cross-platform installer, such as InstallAnywhere or InstallShield, may be bundled with the service and made available at runtime for creating an installer for each target platform. This method is problematic, however, due to the difficulty and expense of licensing the installer for shipment, as well as in the size of the resulting packages for each target architecture. Additionally, this method makes it difficult to subsequently add additional supported platforms.
Alternatively, platform-specific tools (such as WinZip for Windows, or tar/gzip for Linux) could be used for each supported platform. A disadvantage to this method is that the tools for creating each package must be shipped on each server type. This quickly becomes unwieldy as more supported platforms are added. Additionally, because the packages are not necessarily self-extracting, they may require external software on the target device(s) to facilitate their use. Similarly, in the case of MicroSoft Installer (“MSI”) or Red Hat Package Manager (“RPM”) packages, the requirement for creating the non-native package type at runtime on the server still requires the developer to ship tools for doing so on every supported platform.